최근에 레딧에서 가장 핫한 글이 있어 번역하게 되었습니다.

이 글은 https://mtlynch.io/why-i-quit-google/를 번역했으며,

구글에서 소프트웨어 개발자로 일한 경험을 참고하고자 번역하게 되었습니다.

내가 구글을 스스로 그만두게 된 이유

지난 4년간 저는 구글에서 소프트웨어 개발자로 일했습니다. 그리고 1월 1일 저는 퇴사했습니다. 왜냐하면 구글이 저에게 크리스마스 선물을 주지 않았기 때문이죠.
음, 아마도 그것보단 조금 더 복잡한 이야기를 해야할 것 같습니다.

입사 후 2년

2년 동안 저는 구글을 사랑했습니다.
매년 있는 직원 설문에서 5년 뒤에도 구글에 있을 것 같나요? 라는 질문에 저는 생각할 것도 없이 그렇다고 답해왔습니다.

당연히 저는 5년 뒤에도 구글에 있을 것이었죠. 저는 세계 최고의 엔지니어들과 함께있고, 가장 진보된 개발툴을 사용하며, 세상에서 가장 맛있는 음식을 먹었으니까요.

[개발자님 케익 더 드실래요? 공짜에 무제한입니다.]

[아뇨 괜찮아요 마사지 예약한 것도 늦었는데 걔도 공짜거든요]

제 최근 업무 평가는 “기대 이상으로 매우 잘함”이어서 그대로 쭉 지냈다면 저는 곧 시니어 개발자로 승진을 할 수 있었습니다. 좋은 직함이죠! 제 경력이 끝나고 나서도 저는 이렇게 말하고 “그래, 나 구글에서 시니어 개발자였어” 사람들은 인상깊게 듣겠죠.

제 매니저도 제가 곧 승진한다고 확인시켜 주었습니다. 그가 보기에 저는 이미 시니어 레벨의 일을 할 역량이 되었던거죠. 저는 이제 그것을 진급 위원회에 증명할 만한 적절한 프로젝트만 있으면 되었습니다.

매니저가 승진을 시켜주지 않았나요?

아니요, 구글의 매니저들은 직접적으로 보고서를 제출할 수 없어요. 그들은 투표조차 하지 않아요.
대신에 승진에 대한 결정은 상위 레벨의 개발자들과 매니저로 이루어진 작은 위원회에서 옵니다. 그들은 제 심사를 하기전까지 저에대해 들어본 적이 없는 사람들이죠.

그다음에 진급 위원회는 다른 사람들의 서류와 같이 제 서류를 리뷰합니다. 그리고 누가 승진을 하고 누가 승진을 하지 못할지를 하루종일 검토합니다.

제 2년간의 꿀같은 시간동안, 이 시스템은 저에게 괜찮게 들렸습니다. 당연히 제 운명은 저를 한번도 만나보지 못한 사람들이 있는 이해할 수 없는 위원회의 손에 있겠지만요. 그들은 편애를 한다거나 정치적인 이유로 얼룩져 있지 않을 것이고, 그들은 저의 높은 수준의 코드와 빈틈없는 공학적 결정에 대한 저의 과거를 알아볼 것이라고 생각했습니다.

실제로는 그렇지 않았습니다.

제가 첫 승진 서류를 준비하기 전에 저는 그 과정이 어떻게 돌아가는지에 대한 논리에 대해 생각을 해본적이 없었습니다.

제 머릿속에서 위원회는 전지적이고 공평한 독립체였습니다. 만약 제가 매일 문제를 해결하기 위해 적절한 문제를 선택하고, 코드베이스를 개선시키고, 팀원이 효과적으로 일하는 것을 도와주면 위원회가 마법같이 이것을 알고 저에게 보상을 해줄 것이라고 생각했습니다.

놀랍지 않게도, 그렇게 일이 돌아가진 않았습니다. 그걸 알아내는데 2년이 걸렸어요.

순진하게 일만 하기

그떄까지의 제 주요 책임은 레거시 데이터 파이프라인이었습니다. 몇년동안 유지보수 단계에 있었지만 부하가 증가하면 파이프라인은 압력을 받고 삐걱거렸죠.

파이프라인은 자주 조용히 죽거나 잘못된 출력을 했습니다. 그 실패들을 파악하는데 시간이 걸렸는데 왜냐하면 초기의 디자인 스펙 이후에 아무도 문서를 쓰지 않았기 때문입니다.

저는 자랑스럽게 그리고 사랑스럽게 파이프라인을 정상적으로 고쳤습니다. 많은 버그를 고치고 테스트를 자동화해서 버그가 발생하지 않게 했습니다. 죽거나 모던 라이브러리로 대체될 수 있는 수천줄의 코드를 지우고 저는 파이프라인에 대해 배우면서 체계적인 지식을 팀원들이 이용할 수 있도록 문서화도 했습니다. 제 머릿속에 고립되어 있는 것 대신에요.

문제는, 제가 승진 시기를 알게 되었을 때 이것들 중 어느것도 수량화 할 수 있지 않았습니다. 저는 제가 구글에 미친 긍정적인 영향들 중 어떤것도 증명할수 없었죠.

측정 되지 않은 것은 하지 않은 일이다.

파이프라인은 많은 것을 측정하지 않았습니다. 측정된 것 중 하나는 더 안좋게 보였죠. 제가 버그를 발견한 것은 전체 버그의 숫자를 증가시켰습니다. 파이프라인의 실패도 증가했는데 잘못된 데이터가 조용히 통과하는것 대신에 저는 예상되지 않은 동작에 대해 빨리 실패하도록 만들었습니다. 저는 개발자들이 그 잘못들을 고치는데 드는 시간을 과감하게 줄였습니다. 하지만 그 개발시간에 대해 측정된 것은 아무것도 없었습니다.

제 다른 일도 서류상으로 좋아보이진 않았습니다. 가끔씩 저는 제 프로젝트를 몇주 혹은 몇달간 중지하고 발표가 임박한 팀원을 도왔습니다. 팀을 위해서 올바른 결정이었지만, 승진 서류에서는 인상적이지 않았습니다. 진급 위원회에게는 제 팀원의 프로젝트는 많은 개발자들의 협력이 필요한 크고 중요한 일이었습니다. 만약 그들이 제가 그들을 돕도록 만들었다면, 그들이 강력한 리더십을 가지고 있다는 증거였을 것입니다. 저는 단지 일이 관련이 없는 아무 생각 없는 사람이었기 때문에 그 순간에 선수를 칠 수 있었습니다.

저는 제 첫 승진 서류를 제출했고, 제가 두려워했던 결과가 나왔습니다. 진급 위원회는 제가 기술적인 복잡함을 다루는 것을 증명하지 못했다고 말했습니다. 그들은 제가 구글에 기여한 것들을 보지 못했습니다.

[저는 누구도 이해하지 못한 컴포넌트에 대해 문서화를 했습니다.]

[누구나 문서화는 할 수 있어. 구글에 도움이 되었다는 것을 측정할 수 있는 것을 보여줘]

[이건 우리의 빌드를 깨는 불필요한 코드에요 저는 2주동안 이걸 없엤습니다.]

[누구나 코드를 지울 수 있어. 진짜 승진할 자격이 있는 사람들만이 코드를 작성할 수 있지.]

[모두들 Dave가 개발한 새로운 기능을 건드리는것을 두려워해요. 그래서 저는 End-to-End 테스트를 작성했어요.]

[그건 승진될만한 것 같은데?]

[승진 인증서]

[End-to-End 테스트 없이 대담하게 새 기능을 개발한 Dave에게.]

실패를 통해 배운 것들

그 실패는 힘든 일이었지만 저는 낙담하지 않았습니다. 저는 제가 저의 수준 이상의 실력을 발휘하고 있다고 느꼈지만, 진급 위원회는 알지 못했습니다. 그건 해결 가능한 문제였습니다.

저는 처음 몇년 동안 너무 순진했다고 생각했습니다.제가 하고 있는 일이 서류상 기록에 남도록 미리 계획을 충분히 세우지 않았습니다. 이제서야 저는 프로세스가 어떻게 진행되는지 이해했고, 같은 일을 계속 하면서 기록을 해나갈 수 있었습니다.

예를 들어, 저의 팀은 잘못된 알람 때문에 수많은 정신없는 이메일 알람을 받고 있었습니다. 예전의 저라면 이런 알람을 그냥 고쳤을 겁니다. 하지만 지금 저는 이 일이 제 승진 서류에 보여질 거라는것을 알고있죠.
알람의 빈도에 대한 시간적인 기록을 위해 저는 먼저 측정하는 것을 시작했습니다. 승진 기간에 저는 인상적으로 보이는, 알람이 감소하는 그래프를 가지게 될 예정이었습니다.

조금 뒤 저는 승진을 위한 것처럼 보이는 프로젝트에 할당되었습니다. 이 프로젝트는 구글에서 가장 핫했고, 핫한 머신러닝에 매우 의존적이었습니다. 프로젝트 내내 주니어 개발자들을 이끄는 것을 저에게 요구했습니다. 이 프로젝트는 일반적으로 진급 위원회에 점수를 딸 수 있었습니다.

휴가 선물이 알려준 경종

몇달 뒤, 전 직원들에게 풍성한 휴가 선물을 주는 그들의 오래 지속된 전통을 끝내면서 구글은 뉴스를 발표했습니다. 대신에 그들은 혜택받지 못한 학생들을 위해 크롬북을 살 예산을 줬습니다.(자선으로 가장한 광고)

조금 뒤에 저는 다음과 같은 대화를 하는 두 직원을 보았습니다.
A: 너는 아직 효과적으로 그 선물을 받고 있는거야. 이러한 삭감은 구글의 주가를 증가시키겠지. 너는 주식을 팔아서 너가 원하는 선물을 살 수 있을거야.

B: 아내에게 크리스마스 선물을 사주는게 아니라 그녀가 사고싶은걸 살 돈을 은행 계좌에 넣어놓는다고 말하라고?

A: 너는 구글과 비즈니스 관계에 있는거야. 만약 너가 너의 아내에게 하는 것처럼 구글이 너에게 선물을 가지고 로맨틱한 관계에 있지않다고 실망한다면 너는 관계에 대해 잘못된 생각을 가지고 있는 거야.

잠시만요. 저는 구글과 비즈니스 관계에 있었습니다.

제가 이걸 깨닫는데 2년 반이 걸렸다는게 이상하게 들릴수도 있어요. 하지만 구글은 단체에 소속감을 생기게 하는것을 아주 잘해줬어요. 우리가 직원이라고 느끼는 것이 아닌, 우리가 구글이라는 것을 느끼게 했죠.

이 대화는 제가 구글이 아니라는 것을 깨닫게 해줬어요. 저는 구글에서 돈을 받는 대신 서비스를 제공할 뿐이었죠.

그래서 만약 구글과 제가 서로의 이익을 위해 존재하는 비즈니스관계에 있다면, 왜 저는 저의 이익이 아닌 구글의 이익을 위한 일들에 시간을 썼을까요? 만약 진급 위원회가 디버깅이나 팀의 일을 도와주는 것에 보상을 하지 않았다면, 왜 저는 그 일들을 했을까요?

승진을 위한 최적화

제가 처음 겪은 승진에 대한 실패는 잘못된 교훈을 가르쳤습니다. 저는 같은 일을 하면서도 진급 위원회에 좋게 포장하는 것을 생각했습니다. 저는 반대로 진급 위원회가 원하는 것을 찾고 오로지 그 일을 했어야만 했는데 말이죠.

저는 새로운 전략을 선택했습니다. 어떤 일을 시작하기 전에 저는 스스로에게 이 일이 진급에 도움이 되는지 물어보았습니다. 만약 답이 ‘아니요’ 라면 저는 하지 않았습니다.

“이걸 5년동안 유지보수할 수 있을까?”에서 “내가 진급될 때까지 유지할 수 있을까”로 제 코드의 품질은 하락했습니다. 저는 제 프로젝트 발표에 위협이 되지 않는 버그는 찾거나 고치지 않았습니다. 저는 유지보수에 대한 모든 책임들을 회피했습니다. 저는 대학교 모집 행사에 자원하는 것도 그만두었습니다. 저는 일주일에 한두번 면접을 보는 것에서 아예 보지 않게 되었습니다.

그리고 저의 프로젝트는 취소되었습니다.

갑자기 우선순위가 바뀌었습니다. 경영진은 제 프로젝트를 인도에 있는 자매팀에게 넘기고 말았습니다. 그 대신에 그 팀은 우리에게 한 프로젝트를 주었습니다. 그 프로젝트는 문서화되어있지 않은 시스템에, 지원이 중단된 인프라 위에 개발되었지만 그럼에도 불구하고 생산에 있어서 중요한 요소였습니다. 저는 자매팀의 코드를 리팩토링해서 새로운 프레임워크로 마이그레이션하는 일을 맡았습니다. 이 업무의 퍼포먼스를 계속 측정 해가면서요.

제 승진에 대해서 이건 몇달간의 방해요소였습니다. 왜냐하면 전 저의 취소된 프로젝트에 대해 어떤 릴리즈도 하지 못했고, 제가 프로젝트에 들인 두달이 무의미해졌기 때문입니다. 제가 상속받은 시스템에 속도를 내는 것이 저에게 몇주가 걸렸습니다. 그리고 그것을 진행하는 작업을 하는 동안 저는 시간을 더 쉽게 잃어버렸습니다.

도대체 저는 뭘 했을까요?

매니저가 저를 프로젝트 중간에 재배치한 것은 6개월동안 세번째였습니다. 매번 그는 그것이 제 업무의 질과는 관계가 없으며 오히려 고위 경영진의 전략 혹은 팀 인원의 변화와 관련이 있다고 저에게 장담했습니다.

이 시점에서, 저는 한발자국 물러나 높은 단계에서 일어나는 일들에 대해 평가했습니다. 매니저는 잊고, 그의 매니저는 잊고, 진급 위원회도 잊었습니다. 만약 저와 구글로 요약한다면요? 우리의 “비즈니스 관계”에 대해 무슨 일이 일어날까요?

글쎄요. 구글은 제가 프로젝트를 끝내는 것을 보기 전까지는 제 일을 판단할 수 없다고 계속 말했습니다. 반면에 구글이 계속 중간에 끼어들어서 저에게 새로운 프로젝트를 할당했기 때문에 저는 어떤 프로젝트도 끝낼 수 없었습니다.

그 다이내믹은 터무니없다고 느껴졌습니다.

[그 책을 열 때 그들은 회복된 DNA로 공룡들을 되살리기 위해서 어떻게 사용해야할지 알아냈습니다.]

[와우!]

[그리고 벨로키라톱스가 부엌문을 열었어요!]

[오 저런,제가 펜을 떨어뜨렸네요. 저를 위해 펜 좀 주워줄래요?]

[제가 말했던 대로…]

[아니요. 새 이야기를 시작해야할 것 같습니다. 그 이야기가 중간에 끊어져서 저는 당신이 좋은 작가인지 ‘전혀’ 모르겠어요]

제 경력은 한시간 동안 저에 대해 생각해 본 익명의 위원회에 의해 좌우되었습니다. 제가 관여하지 않았던 경영진의 결정은 제 경력의 몇개월을 지워 가고 있었습니다.

그 중에서도 최악은, 저의 업무가 자랑스럽지 않았다는 것입니다. “어떻게 하면 이 어려운 문제를 해결할 수 있을까?" 에 대해 스스로 묻는것 대신에 “어떻게 하면 이 문제를 승진을 위해 도전하는 것처럼 보이게 할 수 있을까” 라고 물었습니다. 저는 그것이 싫었습니다.

만약 제가 승진이 되었다 하더라도, 그 이후에는요? 매 승진은 마지막 승진 때보다 기하급수적으로 더 힘들다는 것은 일반적인 상식입니다. 제 커리어를 계속 향상시키기 위해서 저는 훨씬 더 넓은 범위의 프로젝트가 필요하고 더 많은 팀들과의 협력에 관여해야만 했습니다. 하지만 그건 단지 제가 통제할 수 없는 훨씬 더 많은 요인들로 인해, 수개월 혹은 수년을 낭비하기 때문에 그 프로젝트가 실패할 수 있다는 것을 의미했습니다.

대안책은 뭔가요?

이때즈음, 저는 Indie Hackers를 발견했습니다.

Indie Hackers는 작은 소프트웨어 사업의 창립자를 위한 온라인 커뮤니티입니다. 작은 에 강조를 하죠. 이들은 주커버그를 기대하는 사람들이 아니라, 그들에게 요금을 지불하는 겸손하고 이익이 되는 사업을 하고 싶어 하는 사람들이었습니다.

저는 저의 소프트웨어 회사를 차리는데에 항상 흥미가 있었습니다. 하지만 저는 실리콘밸리의 스타트업 밖에 몰랐습니다. 저는 소프트웨어 창립자가 되는것은 대부분의 시간을 자금조달에 쓰고, 나머지 시간동안 어떻게 수만명의 고객들에게 어필할지 고민하는 것이라고 생각했었습니다.

Indie Hackers는 매력적인 대안을 보여줬습니다. 대부분의 멤버는 그들 자신의 돈으로 시작하거나, 풀타임 직업에 대한 사이드 프로젝트로 그들의 사업을 시작했습니다. 그들은 투자자들에게 대답하지 않았고, 익명의 위원회에게 그들 자신을 증명할 필요가 전혀 없었습니다.

단점도 물론 있었습니다. 수입은 꾸준히 감소했고, 더 많은 재앙적 위험에 맞닥뜨렸습니다. 만약 제가 구글에서 천만 달러의 손실을 입혔다고 해도 저는 어떤 결과도 감수하지 않습니다. 저는 사후분석에 대해 보고서를 쓸 것이고, 실패에 대해 배울수 있는 기회를 축하하겠죠. 하지만 이 창립자들 대부분에게 천만 달러의 손실은 사업의 끝과 몇번의 인생동안 갚아야 할 빚을 의미합니다.

Indie Hackers의 창립자들은 그들의 사업에 대한 통제권을 가지고 있었는데, 이 점이 저의 마음을 사로잡았습니다. 그들의 사업이 걷잡을수 없이 성공하든지 몇년동안 침체되든지, 그들은 결정을 내릴 수 있었습니다. 구글에서 저는 내 자신의 프로젝트에 대한 통제권이 없다고 느꼈습니다. 하물며 내 경력의 성장이나 팀의 방향은 말할 것도 없었죠.

저는 몇달동안 고민하고 마침내 결정을 내렸습니다. 저는 Indie Hacker가 되고 싶었습니다.

떠나기 전에 한 마지막 일

3년동안 제 승진에 투자를 한 뒤에도 저는 여전히 구글에서 미완성인 프로젝트를 하고 있었습니다. 저는 아무것도 보여줄 것 없이 떠난다는 생각이 싫었습니다.

퍼포먼스 기간이 끝나기 6주전에 프로젝트가 또다시 취소되었습니다.

사실 저희 팀 전체가 중단되었습니다. 구글에서는 충분히 흔하게 발생하는 일입니다. 퇴사에 대한 완곡한 표현을 할때요. 경영진은 저희 팀의 프로젝트를 인도에 있는 저희의 자매 팀으로 넘겼습니다. 저의 동료와 저는 회사의 다른 분야에서 다시 일을 시작해야 했습니다.

어쩃든 저는 승진을 신청했습니다. 일주일 뒤에 매니저가 저에게 결과를 알려줬습니다. 제 업무 등급은 “최고수준”으로 직원들 중 5%정도가 받는 가장 높은 등급이었습니다. 진급 위원회는 지난 6개월 동안 제가 분명히 시니어 수준의 성과를 보였다고 말했습니다. 이것들은 공교롭게도, 제가 승진을 위해 최적화하고 있던 시간이었습니다.

하지만 그들은 6개월이라는 기록이 충분히 긴 시간이 아니라고 생각했고, 그래서 다음 번에는 더 나은 행운이 따를 거라고 말했습니다.

매니저는 제가 6개월동안 같은 질의 일을 하면 승진할 수 있을 거라고 했어요. 마음이 끌리지 않았다고는 말할 수 없지만, 저는 그때까지 “6개월 후 승진할 수 있는 좋은 기회가 있을거야” 라는 말을 계속 들어왔습니다. 지난 2년동안 말이죠.

이제 떠날 때가 됐다고 생각했습니다.

그 이후

사람들에게 제가 구글을 떠났다고 말할 때마다 그들은 제가 아주 기막힌 아이디어로 스타트업을 차렸다고 가정했습니다. 구글 소프트웨어 엔지니어처럼 편한 직장을 떠나는 건 아주 바보같은 짓인데 말이죠.

하지만 저는 아무 생각 없는 바보였습니다.

제 계획은 각각 몇개월씩 다양한 프로젝트를 시도해보고, 그중에 다음과 같은 성과가 있는지 알아보는 것이었습니다.

• 내가 수익을 낼 수 있는지 보기 위해 KetoHub에서 계속 일한다.
• 내가 자주 사용하는 분산 스토리지 기술인 Sia를 기반으로 비즈니스를 구축한다.
• 글을 쓰는데 더 많은 시간을 보내고 돈을 벌 수 있는 방법을 찾는다.

구글은 일하기에 아주 멋진 곳입니다. 그리고 저는 그곳에 있는동안 다양한 기술들을 익혔어요. 제가 더 배울 것이 있기 때문에 떠나는 것은 어려웠지만 구글같은 회사는 항상 있었습니다. 제가 항상 회사를 창업할 자유가 있는 것은 아니기 때문에, 이 상황이 저를 어디로 이끌지 기대하고 있어요.

댓글

JessieArr

제가 버그를 발견한 것은 전체 버그의 숫자를 증가시켰습니다.

난 사람들이 마치 좋은 소프트웨어 측정법인것처럼 로그기록에 있는 적은 버그갯수에 대해 보상하는걸 싫어해.

나는 걔네를 잡아 흔들면서 말하고싶어.

너는 알려진 버그만 측정했지. 실제로 알려지지 않은 버그의 숫자는 모른다고!!!

너는 알려진 버그로 사람들을 괴롭히고 있어!

버그가 현재 존재하는지에 대해 보여주는 시스템 업타임, 성능, 에러의 숫자, 유저만족도 같은것을 실제로 측정하라고!!!

Zoraxe

ㅇㅇ 문제를 보여주는것 자체가 지표가 되면 아무것도 보여줄 수 없다는 오래된 격언이 있지.

알려진 버그 지표를 볼떄마다 매우 공감함.

JessieArr

그래 나는 버그 숫자가 적다고 그래 우리는 어썸해! 라고 하는다른팀하고 가깝게 일했었어(걔들은 심지어 그걸로 칭찬을 받음)

실제로 나는 이게 모든 버그들에게서 일어나는 3가지 중 하나를 의미한다고 발견했어 .

• 버그가 너무 커서 이건 요구사항의 피쳐라고 말하거나, 지우거나, 버그가 없는 다른걸 만들지
• 버그가 수정할 정도로 크지 않아서 그냥 지웠음
• 버그가 다른팀에 의해 생겼고 걔네 백로그에 기록하기로함 (어떤 종류의 인계인수 없이)
  실제로 어떻게 되었냐면, 그들의 백로그에는 버그가 거의 없었어.
  
  근데 걔네 코드를 가지고 일할때 난 매우 불편했지. 나는 실제로 꽤 많은 버그를 발견했거든.
  
  그리고 나는 시간낭비를 하게 됐다는 것을 알게됐어. 내가 그것을 위해 버그를 만드는 것때문에 힘들었어.